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REMARKS 

Claims 60-62, 64, 69, 73-76, and 89-92 were pending in the present application. By 
virtue of this response, Claim 69 is canceled and Claim 64 is amended. Accordingly, Claims 60-62, 
64, 73-76 and 89-92 are currently under consideration. Amendment and cancellation of claims is 
not to be construed as a dedication to the public of any of the subject matter of the claims as 
previously presented. 

Claim Rejections - 35 USC § 103(a) 

Claims 60-62, 64, 69, 73-76, and 89-92 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over Hogan (U.S. 5,699,434) in view of Tanaka (U.S. 4,885,750). 

The Examiner stated in pertinent part: 

Hogan fails to explicitly disclose that the DSV data patterns are 
incorporated immediately following at least two headers in the control 
data of the application file to ensure the DSV data patterns are 
accesses and wherein information about the size of each header in the 
control data is modified to include the DSV data patterns. 

However, Tanaka et al. teaches placing DSV data patterns in such 
locations (see column 2 lines 43-54 where information about the size 
of the header must incorporate the included DSV data patterns to 
prevent errors). 

Claim Amendments 

Claim 64, the sole pending independent claim, has been amended to read more closely 
on the specification at paragraph 92 and 93 and include subject matter of Claim 69. 

Specifically, paragraph 92 says in pertinent part: 

In this respect, the information about the size of the header, set out in 
control data 23, has been changed to include the data patterns 36. 
This ensures that the DSV data patterns are read. 
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Continuing at paragraph 93: 

FIG. 5 also illustrates the provision of offsets 38 to cause access to 
specific locations of the application file 20. The offsets 38 and/or any 
pointers to specific locations may be changed either to point directly 
to DSV data patterns or to reliably point to locations which have DSV 
data patterns but whose location has been moved to accommodate the 
DSV data patterns. 

Hence as seen in FIG. 5 the size of the header 23 is modified to specifically indicate the 
size of the DSV data patterns shown at 36 and 32, for instance. Also the offsets 38 which are 
pointers are included in the header and these show the pointers to the specific locations of the DSV 
data patterns, per paragraph 93 and as previously recited in Claim 69. 

The goal is to be sure that the DSV data patterns are indeed read by the playback device 
since they are (1) described in the header in terms of their length and (2) pointed to by the pointers 
(offsets). This makes sure that the DSV data patterns are indeed accessed. Of course by making 
sure they are accessed, as now also recited in the final clause of Claim 64, their copy prevention 
effect is enhanced. 

References 

The paragraph of Tanaka referred to above as cited by the Examiner at column 2 lines 

43-53 says: 

One block of the data including the paraties is divided into 59 frames 
FRM0 through FRM58, each of which is added with a header 
including a sync signal SYNC having a predetermined bit pattern, an 
identification signal representing contents of the program, a pre- 
emphasis constant etc., and a digital sum value control bit DSC for 
reducing a dc component and low-frequency components in the 
transmitted digital signals, as shown in FIGS. 6 and 7. And the data 
including the paraties are transmitted frame by frame in synchronism 
with every fourth horizontal sync pulse of the video signal. 
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This paragraph references Tanaka FIGS. 6 and 7 where the most relevant figure is FIG. 
7. FIG. 7 shows the SYNC section which is 1 1 bits long, the ID section which is 4 bits long, the 
DSV section which is 1 bit long, followed by 61 bytes of data (bytes 0 to 60). This single DSV bit 
is the "digital sum value control bit DSC for reducing a dc component and low-frequency 
components in the transmitted digital signals" at Tanaka column 2 lines 48-50 as quoted above. As 
shown, this is a single bit. It is also characterized as a "bit" at Tanaka column 2 line 49. Moreover 
the purpose of this bit is clearly stated in the above passage " for reducing a dc component and low- 
frequency components in the transmitted digital signals" (emphasis added). 

So first this DSV control bit DSC is only a single bit per header. That is, the header for 
the entire block (see FIG. 7) includes only the single digital sum value control bit DSC. Moreover 
the purpose of this bit DSC is clearly stated as "reducing a dc component and low-frequency 
components". As set forth in the present specification, these components are the cause of DSV 
problems. In other words, the purpose of this DSV control bit DSC bit is to reduce DSV type 
problems. It is not explained in Tanaka how this occurs, but clearly the purpose is reduction of 
DSV problems resulting from a dc component and low-frequency components. 

While Tanaka does not explain exactly how this DSV control bit operates, it is well 
known in the field. See for instance Kayanuma et al. U.S. 6,861, 965B2 which explains such DSV 
control bits. (This patent is cited here to further explain the disclosure of Tanaka.) See Kayanuma 
column 6, beginning line 3 1 : 

The symbol "#" is a DSV control bit and optionally or selectively 
takes "0" and "1" in accordance with the value of the DSV obtained 
from the channel bit train produced by a concatenation of the code 
words. 

This makes it clear that, as well known, DSV control bits by are only single bits and can 
only have the 0 or 1 value, hence emphasizing that this is a single bit. Moreover this single DSV 
control bit indicates the value of the DSV of the following data and is not itself a DSV pattern. 
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Further description explaining this DSV control bit is at Kayanuma column 7, beginning 
line 50, carrying over to column 8, beginning line 27. The most relevant passage appears to be 
column 8, beginning line 19: 

It is guaranteed that the DSV control bit "0" or "1" in the code 
conversion tables shown in FIGS. 1 to 4 never violates the restriction 
of the number of the continuous 2T patterns and the run length 
restriction, irrespective of the code word concatenated before or after 
the code word. Thus, at the appearance of the DSV control bit, the 
run length of the channel bit train before/after it does not need to be 
checked and "0" or "1" is arbitrarily selected as the DSV control bit. 

Further see column 9, beginning line 33 which relates to the Tanaka disclosure: 

Each SYNC code or pattern includes a single DSV control bit. The 
DSV control bit in the code conversion table is provided for only a 
part of the code words. 

This reference SYNC is similar to the disclosure of Tanaka FIG. 7 referenced by the 
Examiner which shows the DSV control bit in the context of the sync signal SYNC. Tanaka states, 
as referenced by the Examiner, at column 2, beginning line 43: 

One block of the data including the paraties is divided into 59 frames 
FRM0 through FRM58, each of which is added with a header 
including a sync signal SYNC having a predetermined bit pattern, . . . 
and a digital sum value control bit DSC for reducing a dc component 
and low-frequency components in the transmitted digital signals, as 
shown in FIGS. 6 and 7. 

Therefore it is clear that Kayanuma discloses exactly the same DSV control bit as 
Tanaka, which is for controlling DSV by giving an indication of the DSV value of associated data, 
but is not itself a "DSV data pattern" since it is in every case only a single bit in each frame. 

Hence there is only a single DSV control bit in Tanaka per frame, not a data "pattern". 
Moreover the purpose of Tanaka's DSV control bit is as usual to help to reduce (control) DSV 
problems. So this bit DSC is neither a data pattern (it is only a single bit) and moreover its purpose 
is to prevent DSV problems. Note that there is no description in Tanaka of deliberately introducing 
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DSV problems; apparently in Tanaka (as in Kayanuma) these are naturally occurring DSV 
problems. 

Rejection Traversed 

Therefore the rejection of Claim 64 as previously pending is traversed. First, Claim 64 
at line 4 recites "incorporating into the application file DSV data patterns". While admittedly 
Hogan has DSV data patterns, it is clear as established above that Tanaka does not. Tanaka only 
has the single DSV control bit DSC. Moreover the whole purpose of DSV control bit DSC in 
Tanaka as explained above is to reduce DSV problems. So Tanaka teaches away from both Hogan 
and the present invention. Hence it is not seen why one would take the DSC bit from Tanaka and 
combine it with Hogan since they have opposite purposes, Hogan to cause DSV problems and 
Tanaka to reduce them. Moreover Hogan deals with deliberately added DSV data patterns . Instead 
Tanaka only has the single DSV control bit. Hence it is not seen why taking the single bit in the 
header of Tanaka and combining with the teachings of Hogan would result in the present invention. 
This combination would instead result in a single DSV control bit being present in the header . Of 
course the single DSV bit would not have the copy protection DSV effect as in Hogan, but would 
have the positive (DSV reduction) effect as indicated by Tanaka. Hence Tanaka and Hogan teach 
opposites. It is not seen how or why they would be combined to meet the present invention. So the 
rejection of Claim 64 as previously pending is traversed. 

Applicant earlier made arguments directed to the inapplicability of Tanaka to which the 
Examiner responded beginning at page 4 of the current Office Action. The Examiner stated in 
pertinent part at page 5 "With respect to Applicant's argument the Tanaka teaches away from a 
combination with Hogan because Tanaka teaches a single bit and this bit is used to reduce the 
errors, Tanaka is merely relied upon to teach placing DSV information in the specific location 
immediately following at least two headers and the control data of the application file.... When 
combined with Hogan, the DSV patterns of Hogan would be placed following at least two headers 
with the corresponding size information changed to reflect this addition...." (Emphasis added.) 
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However it is respectfully submitted this reasoning is not well supported. The Examiner 
here characterizes the DSV control bit in Tanaka as being "DSV information". However the sole 
purpose of the DSV control bit is to indicate DSV values and so to control DSV problems. It is not 
a DSV "data pattern". Further, since the DSV control bit is by its nature control data, Tanaka 
naturally teaches putting this DSV control bit in the header itself, but not following the header. 
Hence in this first respect even the combination of Hogan and Tanaka fails to meet Claim 64 
because the claim recites "the DSV data patterns are incorporated immediately following at least 
two headers " (emphasis added). Instead in Tanaka the DSV control bit is in the header (see his FIG. 
7) since it is a control bit and not actual data of any kind. Hence even the combination of Hogan 
and Tanaka in that respect fails to meet Claim 64 as to the location of the DSV patterns. The 
Examiner incorrectly characterized the effect of his combination in that respect since the 
combination of Tanaka with Hogan would result in putting some sort of information relating to 
DSV in the header , which is what Tanaka teaches. This is not the same as following the header as 
recited in the claim. 

Moreover the Examiner on page 3 of the Action said "However, Tanaka et al. teaches 
placing DSV data information in such locations (see column 2 lines 43-54 where information about 
the size of the header must incorporate the included DSV data patterns to prevent errors)." But this 
is not an accurate characterization of Tanaka. The size of Tanaka' s header would only indicate that 
the DSV control bit is a single bit . Tanaka' s header does not include information about the size of 
any DSV data patterns . There is a significant difference between DSV data patterns themselves and 
the DSV control bit which is an indication of the amount of DSV and is intended to control same. 
Moreover the DSV control bit is only a single bit, 0 or 1. It provides only limited information about 
the actual DSV value, since it merely indicates a DSV correction may be needed. In that sense it 
does not really provide any useful information about DSV except its presence or not. Also of 
course a single control bit as in Tanaka is not properly characterized as a "data pattern" since in this 
respect control data is different from user-type data. "Data patterns" are data and not part of the 
control data. 
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Hence it is respectfully submitted the Examiner mischaracterized Tanaka in saying both 
that (1) Tanaka teaches information about the size of each header and (2) the Tanaka control data is 
modified to include the DSV data patterns. Since the Tanaka DSV control bit is always a single bit 
per header there is no need to modify the size of the header to indicate anything about the DSV 
control bit length. It is different in accordance with the present invention where the DSV data 
patterns are of various lengths and it is important to make sure that they are read so one modifies the 
header to include the length of the specific DSV data patterns of interest. These DSV data patterns 
may well vary in length and being a "pattern" they are always more than a single bit. Hence the 
Examiner's reasoning in reading the prior version of Claim 64 on Tanaka is not well grounded in 
the teachings of Tanaka or Hogan. 

So again, the rejection of Claim 64 as previously pending is traversed for these 
additional reasons. 

Claim 64 As Amended Additionally Distinguishes Over the References for Two Reasons 

As pointed out above, Claim 64 as further amended in its final clause now reads "for 
each header information about the size of the header in the control data is modified to include 
information on the size of at least one of the DSV data patterns and at least one pointer or offset in 
the control data which points to the location of the DSV data patterns in the application file to 
ensure that the DSV data patterns are read" (emphasis added). This reads on (1) paragraph 92 and 
(2) earlier pending Claim 69. There are two elements here. First, the header indicates the size of at 
least one of the DSV data patterns. As pointed out above, Tanaka with his DSV control bit does not 
do this. He is not concerned with the size of any DSV data patterns, but only some indication as to 
the amount of the DSV itself. This is expressed by a single bit which inherently cannot express 
particular size information. Hence clearly Tanaka fails to meet this aspect of Claim 64. 

Further the subject matter of Claim 69 referred to above and described in paragraph 93 
and illustrated in FIG. 5 as being the offsets 38 is not shown in Tanaka as admitted by the Examiner, 
who accordingly cited Official Notice in rejecting Claim 69, see Action at page 4. Tanaka's DSV 
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control bit only indicates (approximately) the DSV value . It does not indicate anything to do with 
DSV location . In fact the whole point of Tanaka's well known DSV control bit is to control 
undesirable DSV, not to have any DSV data patterns read. In fact any DSV problems in Tanaka are 
naturally caused and are not purposely introduced and of course his purpose is to limit DSV effects, 
not to prevent copying by inducing DSV problems. So there would be no reason to use a pointer in 
Tanaka, even if pointers are well known. 

Moreover, even without considering Tanaka, there is no reason to provide a pointer to 
Hogan's DSV data patterns. Hogan does not describe any alterations to control data relating to 
ensuring access to his DSV patterns, and assumes his DSV data patterns would be accessed and 
read. He does (see col. 7, lines 6-14) refer to the sync data and "DSV control" which (possibly) 
refers to the DSV control bit in SYNC, the same as Tanaka. But Hogan does not suggest any need 
for a pointer here. The mere Official Notice of the existence of pointers is insufficient to support a 
rejection; there must be some reason to introduce a pointer where the references do not disclose any 
need for same. No such need was cited by the Examiner, and the mere existence of pointers is 
insufficient for a rejection. Hence also the second aspect of Claim 64 as amended is non-obvious 
and Claim 64 thereby additionally distinguishes over the references. 

So even the combination of Tanaka and Hogan (which combination does not make sense 
or have sufficient justification as pointed out above) even when supplemented by Official Notice 
fails to meet Claim 64 both as previously pending and as amended. Therefore Claim 64 is allowable 
thereover. 

The remaining claims are all dependent upon Claim 64 and allowable for at least the 
same reasons as the base claim. 
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CONCLUSION 

In view of the above, all pending claims in this application are believed to be in 
immediate condition for allowance, and the Examiner is respectfully requested to enter this 
amendment due to the RCE, withdraw the outstanding rejections of the claims, and pass this 
application to issue. If it is determined that a telephone conference would expedite the prosecution 
of this application, the Examiner is invited to telephone the undersigned at the number given below. 

In the event the U.S. Patent and Trademark Office determines that an extension and/or 
other relief is required, Applicant petitions for any required relief including extensions of time and 
authorizes the Commissioner to charge the cost of such petitions and/or other fees due in connection 
with the filing of this document to Deposit Account No. 03-1952 referencing Attorney Docket No. 
136922004600 . 

Rule 34 

This paper is filed under Rule 34; the correspondence address remains that of Patent 
Department, Macrovision Corporation. 

Dated: June 3, 2009 Respectfully submitted, 

Norman R. Klivans 

Registration No.: 33,003 
MORRISON & FOERSTER LLP 
755 Page Mill Road 
Palo Alto, California 94304-1018 
(650) 813-5850 
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